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1  Purpose 

The  purpose  of  this  document  is  to  define  the  process  and  material  requirements  for 
documentation  and  software  deliveries  made  to  the  Defense  Information  Systems  Agency  (DISA), 
Center  for  Integration  (CFI),  Configuration  Management  (CM)  Division  at  the  Operational 
Support  Facility  (OSF)  location  in  Sterling,  Virginia.  The  CFI  currently  provides  support  to  two 
major  joint  programs  where  DISA  is  the  Executive  Agent  (EA).  They  are  the  Defense 
Information  Infrastructure  (DII)  Common  Operating  Environment  (COE)  and  the  Global 
Command  and  Control  System  (GCCS)  programs.  Programs  such  as  the  Global  Combat  Support 
System  (GCSS)  and  the  Electronic  Commerce/Electronic  Data  Interchange  (EC/EDI)  are 
supported  out  of  the  DISA  COOP  Test  Facility  (DCTF)  in  Slidell,  Louisiana,  and  have  their  own 
set  of  delivery  requirements. 

This  document  supersedes  all  previous  versions.  All  memorandums  relating  to  delivery 
requirements  are  also  superseded  by  this  document. 

Documentation  and  software  deliverables  must  be  approved  and  sanctioned  by  the  cognizant 
engineering  authority,  either  the  DII  COE  Engineering  Office  or  the  GCCS  Engineering  Office, 
prior  to  scheduling  a  delivery  meeting  to  the  CFI. 

Deliveries  not  made  in  accordance  with  this  document  are  subject  to  being  immediately  rejected 
by  the  CM  Division  at  the  time  of  delivery. 

2  General  Delivery  Requirements 

Deliveries  to  the  CFI  may  consist  of  documentation,  software,  or  both.  Documentation  will 
include  general  policy  documents  such  as  the  Dll  COE  Integration  and  Runtime  Specification  (I 
&RTS),  the  Dll  COE  Software  Requirements  Specifications  (SRSs),  and  the  GCCS  System  and 
Network  Management  Concept  of  Operations  as  well  as  segment  related  documents  such  as 
Installation  Procedures  (IPs)  or  Software  Version  Descriptions  (SVDs).  Software  will  include, 
but  is  not  limited  to,  source  code,  the  DII  COE  kernel  via  DISA  developers,  the  DII  COE 
applications,  the  GCCS  mission  applications,  test  data,  and  the  kernels  supplied  by  the  DII  COE 
Kernel  Platform  Certification  (KPC)  Program.  This  document  and  its  references  ensure  deliveries 
made  to  the  CFI  are  done  in  a  standardized,  accountable  way  so  the  DISA  CM  Division  can 
maintain  the  vast  library  of  documentation  and  software  entities. 

It  is  vitally  important  that  deliveries  of  software  and  documentation  to  the  CM  Division  are 
properly  identified  with  the  program  for  which  they  are  being  delivered.  The  GCCS  Chief 
Engineer  has  stated  that  GCCS  products  must  not  specify  the  DII  COE  on  their  cover  pages  or 
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labels.  Likewise,  DII  COE  developers  should  not  place  GCCS  on  their  cover  pages  or  labels. 
Anyone  unsure  of  which  program  their  delivery  applies  to  should  contact  either  of  the  engineering 
offices  for  clarification. 

Unlimited  distribution  of  this  entire  document  is  authorized.  The  document  will  be  posted  on 
both  the  DII  COE  HomePage  (unclassified  only)  and  the  GCCS  HomePages  (unclassified  and 
secret). 

3  Documentation  Delivery  Specifications 

3.1  General  Guidance 

This  section  describes  the  requirements  for  documentation  deliveries.  Documents  delivered  to  the 
CFI  fall  into  one  of  two  categories.  The  first  category  contains  those  documents  being  delivered 
that  are  programmatic  in  nature  and  have  no  associated  software  applications.  An  example  of  this 
would  be  the  Dll  COE  I&RTS.  The  second  category  is  software  documentation.  Every  piece  of 
software,  whether  it  is  a  kernel,  a  segment,  or  source  code  has  a  set  of  associated  documentation. 
Software  may  be  delivered  without  the  entire  set  of  associated  documentation  provided  a  waiver 
has  been  obtained  from  the  cognizant  Chief  Engineer.  Section  6  further  describes  the  waiver 
process.  The  following  paragraphs  provide  the  minimum  requirements  for  documentation 
deliveries. 

3.2  DII  COE  Developer  Documentation  Requirements  (DII  COE  DDR) 

Developers  of  DII  COE  software  will  adhere  to  an  additional  set  of  developer  documentation 
requirements  beyond  those  identified  in  this  document.  Those  requirements  are  found  in  the 
current  version  of  the  Defense  Information  Infrastructure  (DII)  Common  Operating  Environment 
(COE)  Developer  Documentation  Requirements  (DDR). 

The  DII  COE  DDR  establishes  the  requirements  for  the  type,  content,  and  format  of  all 
documentation  required  by  contract  or  other  binding  agreement  to  be  submitted  with  the  delivery 
of  DII  COE  software.  The  documentation  requirements  were  derived,  in  part,  from  MIL-STD- 
498  Software  Development  and  Documentation ,  dated  5  December  1994,  and  customized  for  DII 
COE  documentation.  It  is  the  purpose  of  the  DII  COE  DDR  to  define  a  set  of  requirements  for 
DII  COE  documentation  applicable  to  all  DII  COE  developers  that  will  achieve  useful,  well- 
organized,  and  usable  DII  COE  documents.  It  is  also  intended  to  result  in  documentation  that  is 
consistent  in  the  location,  content,  and  presentation  of  information  regardless  of  the  documents 
origin. 

The  following  list  of  documents  are  those  specified  in  the  DII  COE  DDR.  These  are  required  by 
the  DII  COE  Engineering  Office  for  DII  COE  software  deliveries  unless  the  particular  document 
has  been  specifically  waived.  The  documents  are: 

-  Software  Version  Description  (SVD) 
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-  Installation  Procedures  (IP) 

-  System  Administrators  Manual  (SAM)  Note  1 

-  Users  Manual  (UM)  Note  1 

-  Programmers  Manual  (PM)  Note  1 

-  Application  Program  Interface  Reference  Manual  (APIRM)  Note  1 

-  Software  Product  Specification  (SPS)  Note  2 

-  Database  Design  Document  (DBDD)  Note  3 

-  Software  Test  Plan  (STP) 

-  Software  Test  Description  (STD) 

-  Software  Test  Report  (STR) 

-  Software  Design  Description  (SDD)  Note  2 

-  Interface  Design  Document  (IDD)  Note  2 

-  Errata  Sheet  (ES)  Note  2 

Note  1 :  If  the  segment  being  delivered  is  a  COTS  product,  then  the  developer  must  deliver  a  copy  of  the  manufacturer's 
documentation  which  provides  the  equivalent  information. 

Note  2:  At  Government  Request.  This  document  is  to  be  delivered  at  the  request  of  the  cognizant  Chief  Engineer. 

Note  3:  Required  if  segment  being  delivered  is  a  database  segment. 

The  Delivery  Checklist,  contained  in  Appendix  B,  is  based  in  part  on  the  complete  list  of 
documentation  required  by  the  DII  COE  DDR.  On  delivery  of  any  software,  to  be  discussed  in 
detail  in  Section  5,  the  developer  will  provide  a  completed  checklist  which  will  indicate  the  status 
of  each  and  every  document.  It  is  mentioned  here  to  draw  the  readers  attention  to  the  waiver 
process  described  in  Section  6  since  every  document  must  be  accounted  for.  However,  not  all 
documents  listed  may  pertain  to  or  be  required  for  the  software  being  delivered.  Some  documents 
are  automatically  waived  for  certain  types  of  software. 

In  the  case  of  a  discrepancy  or  conflict  between  this  document  and  the  DII  COE  DDR,  the  DII 
COE  DDR  will  take  precedence  for  all  DII  COE  software  documentation  deliveries.  Should 
clarification  be  required  the  DII  COE  Engineering  Office  can  be  contacted  via  unclassified  e-mail 
at:  coeengr@ncr.disa.mil.  The  DISA  CM  Division  should  be  courtesy  copied  on  all  e-mail 
correspondence  at  cm@ncr.disa.mil. 

3.3  GCCS  Developers  Adherence  to  the  DII  COE  DDR  Requirements 

The  GCCS  Chief  Engineer  directs  that  developers  of  GCCS  mission  application  software  are 
required  to  adhere  to  the  developer  documentation  requirements  identified  in  the  DII  COE  DDR. 
Thus,  the  DII  COE  and  GCCS  documents  will  parallel  each  other. 

In  the  case  of  a  discrepancy  or  conflict  between  this  document  and  the  DII  COE  DDR,  the  DII 
COE  DDR  will  take  precedence  for  all  GCCS  mission  software  documentation  deliveries.  Should 
clarification  be  required,  GCCS  mission  application  developers  should  submit  their 

request  through  the  GCCS  Engineering  Office  to  the  DII  COE  Engineering  Office.  The  DISA 
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CM  Division  should  be  courtesy  copied  on  any  e-mail  correspondence  at  cm@ncr.disa.mil. 

3.4  DII  COE  Kernel  Platform  Certification  (KPC)  Program  Additional  Unique 
Documentation  Requirements 

Developers  submitting  DII  COE  kernels  to  the  CFI  under  the  auspices  of  the  DII  COE  Kernel 
Platform  Certification  Program  will  adhere  to  the  DII  COE  DDR.  However,  additional 
documents  will  be  required  from  developers  besides  those  specified  in  the  DII  COE  DDR.  These 
additional  documents  are  identified  in  the  Defense  Information  Infrastructure  (DII)  Common 
Operating  Environment  (COE)  Kernel  Platform  Certification  Program  document,  current 
version.  As  an  example,  two  additional  documents  required  by  the  KPC  Program  are  the  Dll 
COE  Kernel  Platform  Certification  Application  Form  and  the  Government  Supplied  Kernel 
Software  (GSKS)  Build  Document. 

Should  clarification  or  additional  information  be  required  concerning  the  KPC  Program,  please 
contact  the  DII  COE  Engineering  Office.  Address  comments  and/or  concerns  to: 

Mr.  Fritz  Schulz  unclassified  email:  schulzf@ncr.disa.mil 

DISA/JEXF  phone:  (703)  681-2350 

DII  COE  Kernel  Platform  Certification  Program  fax:  (703)  681-2813 

5600  Columbia  Pike 

Falls  Church,  VA  22041 

3.5  Physical  Document  Delivery  Requirements 
3.5.1  Printed  (Hard  Copy)  Requirements 

When  a  hardcopy  of  a  document  is  required  for  the  delivery,  the  developer  shall  provide  one  (1) 
single-sided,  unbound  document  of  good  quality  that  is  reproducible.  This  requirement  applies  to 
all  government  and  contractor  produced  documentation.  For  deliveries  of  COTS  documentation, 
associated  with  segmented  COTS  applications,  the  one  hard  copy  is  acceptable  in  the  form  and 
style  normally  produced  by  the  COTS  vendor  for  the  distribution  with  their  commercial  product. 

There  is  a  significant  difference  between  the  hard  copy  requirements  of  the  DII  COE  Engineering 
Office  and  the  GCCS  Engineering  Office.  For  documents  required  for  a  delivery,  i.e.,  those  not 
waived,  the  following  table  provides  the  listing  of  which  hard  copy  documents  are  required. 


Document 

DII  COE 

GCCS 

Delivery  Letter 

Required 

Required 
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Delivery  Checklist 

Required 

Required 

Installation  Procedures  (IP)  DII  COE  Only 

Required 

Software  Version  Description  (SVD) 

Required 

Required 

System  Administrators  Manual  (SAM) 

Required  (Note  1) 

Users  Manual  (UM) 

Required  (Note  1) 

Software  Product  Specification  (SPS) 

Required  (Note  2) 

Database  Design  Document  (DBDD) 

Required  (Note  3) 

Software  Test  Plan  (STP) 

Required 

Software  Test  Description  (STD) 

Required 

Software  Test  Report  (STR) 

Required 

Application  Program  Interface  Reference  Manual  (APIRM) 

Required  (Note  1) 

Programmers  Manual  (PM) 

Required  (Note  1) 

Software  Design  Description  (SDD) 

Required  (Note  2) 

Interface  Design  Document  (IDD) 

Required  (Note  2) 

Errata  Sheet  (ES) 

Required  (Note  2) 

GCCS  Segment  Release  Bulletin  (SRB)  GCCS  Only 

Required 

DII  COE  Kernel  Platform  Certification  Application  Form  KPC  Only 

Required 

Government  Supplied  Kernel  Software  (GSKS)  Build  Document  KPC  Only 

Required 

Printouts  of  the  contents  of  the  SegName  and  Version  Descriptor  Files 

Required 

Required 

Intellectual  Property  Rights  Agreement  Attachment 

Required 

Required 

COTS  Vendor  Y2K  Compliance  Attachment 

Required 

Required 

Table  1:  Printed  (Hard  Copy)  Requirement 

Note  1 :  If  the  segment  being  delivered  is  a  COTS  product,  then  the  developer  must  deliver  a  copy  of  the  manufacturer's 
documentation  which  provides  the  equivalent  information. 

Note  2:  At  Government  Request.  This  document  is  to  be  delivered  at  the  request  of  the  cognizant  Chief  Engineer. 

Note  3:  Required  if  segment  being  delivered  is  a  database  segment. 

3.5.2  Electronic  (Soft  Copy)  Requirements 

The  delivery  shall  include  one  (1)  electronic  copy  of  each  document.  For  government  and 
contractor  produced  documentation  the  media  may  be  3  2  "  floppy  diskettes,  CDROMs,  or  ZIP 
drive  diskettes.  The  choice  of  media  for  COTS  documentation  depends  on  what  the  COTS 
vendor  ships  as  the  standard  media  for  its  commercial  base.  For  diskettes,  CDROMs,  and  ZIP 
drive  diskettes  that  contain  multiple  documents,  an  ASCII  text  file  called  toc.asc  must  be  included 
on  each  media  which  describes  the  mediae  contents  by  path,  filename,  and  a  brief  description  for 
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each  entry,  and  the  CM  number  associated  with  each  entry.  The  toc.asc  requirement  does  not 
apply  to  COTS  documentation  media. 

The  electronic  (soft  copy)  documentation  file  format  requirements  differ  between  the  DII  COE 
Engineering  Office  and  the  GCCS  Engineering  Office.  The  DII  COE  Engineering  Office  requires 
that  Microsoft  Word,  Version  6.0,  be  used  for  all  DII  COE  documentation.  The  GCCS 
Engineering  Office  has  authorized  the  use  of  both  Microsoft  Word,  Version  6.0,  and  Corel  Word 
Perfect,  Version  6.1,  at  the  discretion  of  the  GCCS  developer.  Documents  created  on  non- IBM 
compatible  platforms  must  be  readable  in  the  above  specified  format.  In  all  cases  the  file 
extensions  for  the  word  processing  documents  must  be  either  Adoc(§for  Microsoft  Word 
documents  or  Awpd(gfor  Word  Perfect  documents.  Providing  additional  soft  copies  of 
documentation  in  Portable  Document  Format  (PDF)  and/or  Hypertext  Markup  Language 
(HTML)  format  is  optional  though  highly  encouraged.  If  documents  are  provided  in  HTML 
format  then  they  must  be  in  HTML,  Version  3.2.  The  following  table  provides  a  breakdown  of 
the  file  format  types. 


Acceptable  Document  Formats 

DII  COE 

GCCS 

Microsoft  Word,  Version  6.0  (file  extension  must  be  .doc) 

Required 

Developer  Choice 

Corel  Word  Perfect,  Version  6. 1  (file  extension  must  be  .wpd) 

Not  Authorized 

Developer  Choice 

Portable  Document  Format  (PDF) 

Optional 

Optional 

Hypertext  Markup  Language  (HTML),  Version  3.2 

Optional 

Optional 

Table  2:  Electronic  (Soft  Copy)  File  Format  Requirements 

A  media  may  contain  multiple  documents.  Self-extracting  files  (.EXE)  are  permissible  but  there 
may  only  be  one  document  per  compressed  instance.  Multiple  compressed  documents  per  media 
are  allowed.  All  soft  copies  of  COTS  documentation  may  be  submitted  in  the  word  processor 
version  the  COTS  vendor  ships  as  the  standard  for  its  commercial  base.  Please  state  on  the 
delivery  checklist  which  word  processor/version  was  used  for  the  COTS  softcopy  documentation. 

For  soft  copies  of  government  or  contractor  produced  documents,  which  are  delivered  one  per 
diskette,  each  media  label  shall  contain,  at  a  minimum,  the  following  information: 


Segment/Program  Name/Version  Number: 
Document  Title: 

Version  Number: 

Filename: 

Material  Date: 

Security  Classification: 

CM  Number: 


The  program  name  will  be  DII  COE,  GCCS,  or  GCCS-T.  For  GCCS  and  GCCS-T  deliveries,  the 
Program  Version  Number  will  be  the  targeted  GCCS  release.  For  example,  GCCS  3.0,  GCCS 
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3.1,  etc.  Individuals  submitting  DII  COE  documentation  should  leave  the  Program  Version 
Number  blank.  The  Security  Classification  marking  must  be  in  bold  font. 

Documents  too  large  to  fit  on  one  media  may  be  compressed  onto  multiple  media,  in  which  case 
the  media  labels  must  identify  the  media  according  to  the  sequence  in  which  they  will  be  loaded. 
In  such  cases,  after  identifying  the  filename,  the  developer  will  include  the  sequence  number.  For 
example,  1  of  3.  Below  is  an  example. 


Segment/Program  Name/Version  Number: 
Document  Title: 

Version  Number: 

Filename: 

Sequence:  N  of  M 
Material  Date: 

Security  Classification: 

CM  Number: 


Multiple  documents  are  allowed  on  one  diskette  for  soft  copies  of  government  or  contractor 
produced  documents.  However,  to  use  this  packaging  approach,  all  documents  on  the  diskette 
must  pertain  to  the  same  software  segment.  For  diskettes  which  contain  more  than  one  document 
per  diskette,  each  media  label  shall  contain,  at  a  minimum,  the  following  information: 


Program  Name/V  ersion  Number: 

Segment  Name: 

Version  Number: 

Document  Short  Titles:  (e.g.  SVD,  IP,  APIRM,  etc.) 
Filename:  Internal  to  media  in  toe. as c  file 
Material  Date: 

Security  Classification: 

CM  Number:  Internal  to  media  in  toc.asc  file 


One  of  the  key  differences  of  the  multiple  documents  per  diskette  packaging  approach  is  the 
segment  name  must  be  the  second  item  labeled.  A  second  difference  is  only  the  abbreviated  short 
names  of  the  document  titles  will  be  used.  This  short  names  can  be  found  in  paragraph  3.2.  of  this 
document.  When  the  multiple  documents  per  diskette  approach  is  used  they  must  all  have  the 
same  word  processor  version,  Material  Date,  and  Security  Classification.  The  CM  numbers  are 
not  listed  on  the  media  label  since  they  are  internal  to  each  of  the  documents. 

For  either  case  identified  above,  single  or  multiple  documents  per  diskette,  if  a  compression  utility 
is  used  or  if  there  are  special  decompression  instructions,  they  must  be  included  on  the  media  in  a 
separate  file  in  ASCII  format  (e.g.,  readme.txt ). 

COTS  documentation  software  media  will  be  accepted  with  the  vendors  standard  commercial 
media  label. 


The  following  two  examples  are  of  government  or  contractor  produced  media  labels  for  diskettes 
containing  only  one  document.  The  correct  labeling  would  be: 


Program/Version:  DII  COE 

Document  Title:  Software  Requirements  Specification 
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(SRS)  for  the  Network  Management  (NM)  Functional 
Area  of  the  DII  COE, 

Version:  2.0 

Filename:  NETSRS20.DOC 
Material  Date:  19970708 
Security  Classification:  UNCLASSIFIED 
CM  Number:  CM-400-260-01 


Program/Version:  GCCS  3.0 

Document  Title:  Software  Requirements  Specification 
(SRS )  for  Airfields  Database  Segment 
Version:  1.4 

Filename:  AIRDBSEG.WPD 
Material  Date:  19980103 
Security  Classification:  UNCLASSIFIED 
CM  Number:  CM-220-2 10-57 


The  second  example  shown  below  is  of  a  government  or  contractor  produced  diskette  label  where 
the  diskette  contains  five  different  documents  associated  with  the  same  software  segment.  The 
correct  labeling  would  be: 


Program/Version:  GCCS  3.1 

Segment  Name:  TESTAPP3 

Version  Number:  3.2.5. 0/1 1.25c 

Document  Short  Titles:  SVD,  IP,  STP,  STD.  and  STR 

Filename:  Internal  to  media  in  toc.asc  file 

Material  Date:  19971605 

Security  Classification:  UNCLASSIFIED 

CM  Number:  Internal  to  media  in  toc.asc  file 


4  Software  Delivery  Specifications 
4.1  General  Guidance 

The  DISA  CM  Division  at  the  CFI  receives  a  variety  of  software  for  both  the  DII  COE 
Engineering  Office  and  the  GCCS  Engineering  Office.  The  form  and  structure  of  the  software  is 
dictated  by  the  direction  laid  out  in  the  DII  COE  I&RTS  which  provides  detailed  information 
concerning  the  foundation  for  the  various  types  of  software  deliveries.  The  following  abbreviated 
sections  break  down  the  software  deliveries  into  the  various  forms  so  a  developer  making  a 
delivery  better  understands  the  software  delivery  requirements.  Consult  the  I&RTS  if  further 
technical  information  is  required.  The  following  sections  apply  to  both  DII  COE  and  GCCS 
software  submissions. 


4.2  Source  Code  Deliveries 

Source  code  delivered  to  the  CFI  will  come  from  a  variety  of  developers.  One  type  of  submission 
will  be  the  kernel  source  code  which  is  delivered  to  the  CFI  by  the  developer  under  contract  with 
the  DII  COE  Engineering  Office.  This  delivery  will  be  in  the  form  of  a  tar  file.  Another  set  of 
source  code  submission  will  come  from  vendors  participating  in  the  Kernel  Platform  Certification 
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Program.  These  submissions  will  also  be  in  tar  format.  Another  set  of  source  code  will  come 
from  the  developers  of  the  various  government-off-the-shelf  (GOTS)  and  COTS  segments  used 
by  the  DII  COE  or  GCCS  Engineering  Offices.  These  submissions  must  be  in  segmented  form 
with  the  source  code  being  made  available  in  the  segment  itself.  The  DII  COE  I&RTS  identifies 
the  subdirectory  structure  to  be  used  by  every  DII  COE  compliant- segment.  For  some 
applications,  the  source  code  must  be  included  within  the  segment  because  of  shareware  and 
freeware  licensing  issues  associated  with  the  segment.  For  both  GOTS  and  COTS  DII  COE 
segments,  the  DII  COE  Engineering  Office  may  send  the  source  code  software  out  to  a  third 
party,  independent  testing  organization  for  software  quality  assurance  testing.  The  GCCS 
Engineering  Office  may  do  the  same  for  GCCS  mission  applications.  Questions  concerning 
source  code  deliveries  should  be  directed  to  the  appropriate  DII  COE  or  GCCS  Engineering 
Office. 

All  source  code  deliveries  must  include  an  Intellectual  Property  Rights  (IPR)  agreement  at  the 
time  of  submission.  The  IPR  will  be  maintained  by  the  DISA  CM  division.  It  will  be  used  by  the 
appropriate  DII  COE  or  GCCS  Engineering  Office  in  determining  the  extent  of  releasability  of  the 
source  code.  If  the  developer  of  the  application  or  segment  being  delivered  claims  there  is  no 
IPR,  an  agreement  must  still  be  submitted  stating  the  code  in  question  is  freely  distributable. 
Questions  concerning  IPR  agreements  should  be  submitted  to  the  DII  COE  Engineering  Office  via 
the  DISA  CM  division. 

4.3  Kernel  Deliveries 

Kernel  deliveries  will  come  from  either  the  developer  under  contract  with  the  DII  COE 
Engineering  Office  or  from  vendors  participating  in  the  Kernel  Platform  Certification  Program. 
These  deliveries  will  be  in  the  form  of  a  tar  file  in  kernel  installation  format. 

4.4  Tool  Deliveries 

Individual  tools  and  tool  kits  used  in  the  DII  COE  environment  are  created  for  two  different  uses: 
developmental  and  runtime.  The  developmental  tools  can  be  used  in  a  non-DII  COE  compliant 
environment.  The  runtime  tools  are  used  within  the  DII  COE  environment.  Both  of  these 
families  of  tools  must  be  delivered  in  Makelnstall  format  from  the  developer.  This  is  a  change 
from  past  practices  where  the  developmental  tools  were  not  segmented. 


4.5  UNIX-based  Segments 

All  UNIX-based  segments  will  be  delivered  in  Makelnstall  format  from  the  developer.  DII  COE 
UNIX-based  segments  may  be  submitted  with  or  without  using  compression.  All  GCCS  mission 
application  UNIX-based  segments  will  be  submitted  without  using  compression.  Each  delivery  of 
electronic  media  shall  include  on  the  hard  copy  the  exact  command  string  entered  for  its  creation 
and  identification  of  the  operating  system  used  to  create  the  electronic  media. 
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Developers  must  run  their  segments  through  the  VerifySeg  tool  prior  to  creating  the  tapes  used 
for  delivery  to  the  DISA  CM  Division.  Only  a  verified  segment  can  be  delivered  to  DISA  CM 
Division.  The  creation  of  installable  segments  using  the  Makelnstall  tool  will  be  done  by  DISA 
CM  Department  staff. 

4.6  NT-based  Segments 

NT-based  segments  can  be  created  using  two  different  approaches.  In  the  first,  the  full 
segmentation  methodology  is  followed  as  identified  in  the  I&RTS.  The  second  approach  uses  an 
abbreviated  process  used  solely  for  COTS  applications  in  the  NT  environment.  The  abbreviated 
approach  does  not  apply  to  GOTS  software.  In  the  abbreviated  approach,  the  executables  of  the 
application  are  not  contained  within  the  segment.  Instead  the  COTS  software  is  loaded  on  the 
DII  COE  compliant  NT  workstation  from  the  commercial  vendor  supplied  media.  The  DII  COE 
segment  for  the  application  software  is  then  loaded  also.  This  dual  loading  ensures  the  NT 
Registry  and  the  DII  COEInstaller  remain  synchronized  on  the  DII  COE  compliant  NT 
workstation.  The  two  sections  below  identify  the  software  delivery  requirements  for  both  types 
of  NT  segments. 

4.6.1  Full  NT  Segmentation 

All  NT-based  segments  created  using  the  full  segmentation  method  will  be  delivered  in 
Makelnstall  format  from  the  developer.  Prior  to  creating  the  Makelnstall  diskette  the  developer 
must  run  the  segment  through  the  VerifySeg  tool.  In  the  case  of  these  deliveries  there  is  no  need 
for  the  DISA  CM  Division  staff  to  create  installable  segments.  They  are  received  this  way  from 
the  vendor  already. 

4.6.2  Abbreviated  NT  Segmentation 

NT-based  segments  created  using  the  abbreviated  segmentation  approach  are  also  delivered  to  the 
DISA  CM  Division  in  Makelnstall  format.  Engineers,  testers,  integrators,  and  CM  personnel 
must  exercise  caution  though  and  realize  the  segment  will  actually  contain  no  COTS  application 
executables.  The  segment  will  only  contain  the  segment  descriptor  file  information.  Freeware  or 
Shareware  that  requires  the  source  code  to  be  distributed  with  the  application  cannot  use  the 
abbreviated  segmentation  method.  Again,  please  remember  the  COTS  software  is  loaded  on  the 
DII  COE  compliant  NT  workstation  from  the  commercial  vendor  supplied  media. 

4.7  Software  Media  Labeling  Requirements 

4.7.1  Acceptable  Software  Media  Formats  and  Quantity 

The  developer  shall  supply  one  (1)  MASTER  and  one  (1)  BACKUP  copy  of  software  on  the 
appropriate  electronic  media.  The  required  media  is  identified  in  the  table  below. 
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Type  of  Software 

Government  or  Contractor  Produced 

Vendor  Produced 

Operating  System 

GOTS  Media 
Requirement 

COTS-Related  Media 
Requirement  -  Note  1 

COTS  Media  Requirement 

Solaris 

(current  version) 

8mm  tape  or  CDROM 

Note  2 

8mm  tape  or  CDROM 

Note  2 

8mm  tape,  3  2"  diskette,  or 
CDROM  -  Note  2 

HP-UX 

(current  version) 

4mm  tape  or  CDROM 

Note  2 

4mm  tape  or  CDROM 

Note  2 

4mm  tape,  3  2"  diskette,  or 
CDROM  -  Note  2 

NT 

(current  version) 

3  2"  diskette  or  CDROM 

3  2"  diskette  or  CDROM 

3  2"  diskette,  or  CDROM 

Others 

Note  3 

Note  3 

Note  3 

Table  3:  Acceptable  Software  Media  Format  Requirements 

Note  1:  This  column  refers  to  DII  COE  specific  documentation  that  is  produced  to  support  a 
segmented  COTS  application  being  delivered  to  the  CFI.  If  further  clarification  is  required, 
contact  the  DII  COE  Engineering  Office. 

Note  2:  It  is  recommended  that  developers  use  1 12m-length  tapes  for  8mm  media  deliveries  and 
90m- length  tapes  for  4mm  media  deliveries. 

Note  3:  Please  contact  the  DISA  CM  Division  for  guidance  on  the  proper  media  to  be  used  for 
other  operating  systems.  The  DISA  CM  Division  will  coordinate  with  the  DII  COE  Engineering 
Office  and  provide  a  response  back  to  the  developer.  This  area  will  mostly  affect  those  vendors 
participating  in  the  Kernel  Platform  Certification  Program. 

4.7.2  Labeling  Format  Requirements 

External  media  volume  labels  shall  be  typed  or  printed  legibly.  The  following  information  will  be 
identified  on  the  label: 


Software  name: 

Version/Patch  Number: 

Media  Number:  (1  of  2,  2  of  2,  etc.): 

MASTER  or  BACKUP  copy: 

Material  Date:  (YYYYMMDD  format): 

Procedure  used  to  create  media:  (tar.  Makelnstall,  diskcopy,  etc.) 

Operating  System:  (Solaris  2.5.1,  HP-UX  10.20,  NT  4.00,  etc.) 

Program  Name/Version:  (DII  COE,  GCCS  3.0,  GCCS  3.1,  etc.  Note:  Do  not  use  a  DII  COE  Version  Number) 

Security  Classification:  (Unclassified,  FOUO,  Confidential,  Secret,  Top  Secret,  etc.  Note:  The  classification  must  be  in  bold  font.) 
Type  media  (4mm,  8mm,  3  2  "  diskette,  CDROM,  etc.) 

CM  Number: 
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The  following  is  an  example  of  a  properly  designed  external  media  label: 


Software:  TSTAPP 
Version:  3.5.2.2P3/12.0.5a 
Media  Number:  1  of  1 
MASTER 

Material  Date:  19970821 

Procedure:  Makelnstall 

OS:  Solaris  2.5.1 

Program:  DII  COE 

Security  Classification:  Unclassified 

Type  media:  8mm 

CM  Number:  CM-123-123-01 


Multiple  files,  segments,  and  scripts  may  be  combined  on  the  same  media.  It  is  also  permissible 
to  have  both  client  and  server  segments  on  the  same  tape.  Internal  media  labels  shall  contain  the 
same  information  as  the  external  media  label.  For  media  containing  multiple  entries,  the 
software/segment  name,  version  number,  and  CM  numbers  will  not  be  included  on  the  label. 
Instead,  the  CM  Delivery  Letter  for  one  of  the  entries  will  be  cross  referenced.  The  Subject,  the 
Version  Number,  and  Date  of  the  CM  Delivery  Letter  must  be  identified. 

The  following  is  an  example  of  a  properly  designed  external  media  label  that  contains  multiple 
segments  within  the  media: 


CM  Delivery  Ltr:  TAPP1SV,  Ver:  3.2.0.4/23.5b,  19980104 

Media  Number:  1  of  1 

MASTER 

Material  Date:  19970821 

Procedure:  tar 

OS:  HP-UX  10.20 

Program:  DII  COE 

Security  Classification:  Unclassified 

Type  media:  4mm 


Note:  When  multiple  segments  are  combined  on  one  media,  they  must  have  the  same  Material  Date,  Procedure,  OS, 
Program,  and  Security  Classification.  The  font  used  for  media  labels  must  not  be  smaller  than  8  point  (1/9  inch). 

4.8  Year  2000  (Y2K)  Compliance 

As  the  year  2000  draws  closer,  more  and  more  emphasis  is  being  placed  on  Year  2000  (Y2K) 
compliance.  DOD  has  based  Y2K  compliance  on  two  main  criteria.  First,  will  the  applications 
continue  to  process  date  data  accurately  as  we  approach  and  continue  into  the  next  millennium? 
Secondly,  is  the  DOD  standard  date  format  (i.e.  YYYYMMDD)  used?  Both  criteria  must  be 
satisfied  to  be  Y2K  compliant. 

The  DII  COE  is  built  on  top  of  a  variety  of  different  operating  systems.  The  proper  software 
engineering  approach  is  to  make  all  of  the  date/time  calls  to  the  underlying  services  contained 
within  the  operating  system.  The  goal  of  the  DII  COE  Engineering  Office  is  for  the  DII  COE  to 
operate  on  vendor- supplied  Y2K  compliant  operating  systems  by  DII  COE  Version  3.3  which  is 
slated  for  release  on  3  April  1998.  The  assumptions  that  the  operating  systems  will  be  Y2K 
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compliant  are  based  on  information  currently  obtained  from  the  vendors=web  sites. 


Information  will  be  gathered  from  the  Delivery  Letter  to  help  the  DISA  CM  Division  track  the 
status  of  Y2K  compliance  for  DII  COE  kernel  and  COE  segments.  Additional  information 
concerning  Y2K  can  be  found  on  either  the  DII  COE  or  GCCS  HomePages. 

5  Delivery  Instructions 

5.1  Registration  of  Segments 

The  segment  registration  process  is  accessible  via  the  unclassified  DII  COE  or  GCCS  home  pages 
(See  paragraph  8  for  web  site  addresses).  Developers  are  required  to  register  all  new  segment 
prefix  codes  in  accordance  with  the  I&RTS.  For  GCCS  and  DII  COE  new  segments,  developers 
are  requested  to  register  supporting  data  regarding  the  application/system  being  proposed.  The 
developers  will  need  to  register  Group  IDs  and  IP  (TCP/UDP)  Sockets  required  by  a  segment. 

The  I&RTS  (Appendix  D  &  E)  provides  guidance  on  registering  new  segments.  Consult  the 
Configuration  Management  web  pages  for  accessing  DISA  on-line  registration  services.  Once 
registered,  either  the  GCCS  or  DII  COE  Engineering  Offices,  as  appropriate,  will  verify  that  the 
submission  is  authorized  and  resolve  any  conflicts  that  exist.  The  developers  will  ensure  that 
registration  information  is  maintained  current  to  coincide  with  scheduled  deliveries  of  segments. 

5.2  Scheduling  Deliveries 

It  is  best  to  schedule  deliveries  as  soon  as  possible  through  the  DISA  CM  Division  but  no  later 
than  seven  (7)  days  in  advance.  However,  the  DISA  CM  Division  will  attempt  to  accommodate 
deliveries  within  the  seven  day  window  if  scheduling  allows  and  the  cognizant  engineering  office 
approves.  When  scheduling  a  delivery,  the  developer  needs  to  go  to  the  Delivery  and  Scheduling 
System  of  the  On-Line  Databases  link  from  the  Configuration  Management  page  of  either  the 
unclassified  DII  COE  or  GCCS  home  pages  and  go  through  the  scheduling  process.  Developers 
will  have  the  ability  to  modify  (select  another  time  and/or  date)  their  scheduled  delivery  entries  as 
necessary.  Once  you  have  selected  and  scheduled  a  desired  date  and  time  for  the  delivery,  the 
developer  owns  that  time  slot  and  no  one  else  can  schedule  into  that  same  date  and  time. 

However,  the  developers  will  be  unable  to  modify  their  scheduled  deliveries  within  48  hours  of 
the  appointment. 

5.3  Preassignment  of  CM  Numbers 

Developers  are  required  to  obtain  CM  numbers  for  their  documentation  and  software  prior  to 
scheduling  a  delivery.  For  documentation,  this  ensures  the  hardcopy  and  softcopy  versions  will 
have  the  same  CM  number.  For  software  deliveries,  this  allows  the  developer  to  have  the  CM 
numbers  for  inclusion  on  the  media  labels.  The  CM  Divison  Librarian  will  provide  the  appropriate 
CM  numbers  for  the  delivery  based  on  the  receipt  of  the  following  items. 

1.  The  Delivery  Letter 

2.  The  Delivery  Checklist 
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3.  Each  Document  Cover  Page 

4.  Each  Media  Label 

Developers  are  requested  to  fax  this  information  to  the  DISA  CM  Division,  Attention:  CM 
Librarian,  unclassified  fax  at  (703)  735-8504  (primary)  or  (703)  735-8766  (secondary).  Please 
call  (703)  735-8739  to  alert  the  CM  Librarian  that  a  fax  is  inbound.  The  request  for  CM  numbers 
should  be  made  as  early  as  possible  prior  to  delivery  to  facilitate  the  ease  of  the  delivery  meeting. 
All  requests  should  be  made  a  minimum  of  three  working  days  prior  to  the  CM  delivery. 
Otherwise,  the  CM  Division  Librarian  may  not  have  sufficient  time  to  review,  assign,  and  return 
the  appropriate  CM  numbers.  The  information  will  be  returned  to  the  originator  via  fax.  The 
developers  are  requested  to  identify  Point-of-Contact  (POC),  telephone  number,  and  their  fax 
number(s)  on  the  fax  cover  page. 

A  delivery  will  be  rejected  during  the  delivery  meeting  if  the  delivered  documentation  and  media 
does  not  exactly  match  the  title  and  date  information  previously  submitted  during  the  CM  number 
preassignment  process.  The  delivery  can  also  be  rejected  if  the  segment  name  and/or  segment 
prefix  do  not  exactly  match  the  printout  from  the  SegName  and  Version  descriptor  files  provided 
during  the  delivery  meeting.  The  developers  are  required  to  bring  the  CM  Division  faxed  CM 
Number(s)  notification  page(s)  to  the  delivery  meeting  should  verification  or  clarification  be 
required. 

5.4  Delivery  Letter  Requirements 

A  Delivery  Letter  shall  accompany  all  documentation  and  software  deliveries  to  the  DISA  CM 
Division  at  the  CLI.  The  delivery  letter  provides  sufficient  information  to  allow  future  cross- 
referencing  for  tracking  and  accountability  purposes  for  all  items  being  delivered.  The 
instructions  for  filling  out  the  delivery  letter  and  a  template  are  contained  in  Appendix  A.  One  (1) 
copy  of  the  delivery  letter  is  required  at  the  time  of  delivery. 

5.5  Delivery  Checklist  Requirements 

One  (1)  copy  of  a  completed  Delivery  Checklist  will  be  required  for  each  segment  being  delivered. 
The  Delivery  Checklist  ensures  that  all  items  required  at  a  delivery  are  accounted  for.  A  Delivery 
Checklist  is  not  required  for  programmatic  documentation-only  deliveries.  Software  developers 
can  find  instructions  for  filling  out  the  delivery  checklist  and  template  in  Appendix  B . 

5.6  Temporary  Licenses  for  Test,  Integration,  and  Evaluation  Purposes 
5.6.1  COTS  Application  Licensing  Requirements 

Three  (3)  software  licenses  are  required  for  each  application  delivery.  Two  are  used  at  the  CLI  to 
allow  the  Test  and  Evaluation  Division  and  the  Product  Integration  Division  to  legally  run  each 
COTS  segment  submitted.  The  third  software  license  will  be  maintained  by  the  cognizant 
engineering  office  for  use  with  their  Y2K  test  support  organizations.  This  software  license 
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requirement  also  includes  those  applications  being  submitted  in  the  abbreviated  NT  segmentation 
format.  These  licenses  are  used  to  perform  DII  COE  compliance  testing,  functional  testing, 
problem  report  verification  testing,  Y2K  evaluations,  and  GCCS  mission  application  integration 
testing. 

The  licenses  may  be  either  standard  commercial  runtime  license  with  or  without  internal  license 
keys  or  temporary/demonstration  licenses.  The  time  limits  and  host  requirement  of  either  type  of 
license  must  be  explicitly  identified.  If  host  information  is  required  by  the  developer  prior  to 
obtaining  the  necessary  licenses,  please  contact  the  cognizant  engineering  office  for  assistance. 
Three  licenses  must  be  included  in  the  delivery  for  every  new  first-time  COTS  segment  delivery  or 
for  an  upgraded  COTS  version  segment  delivery.  All  licenses  are  maintained  and  accounted  for 
by  the  CM  Division  for  use  within  DISA.  A  developer  does  not  need  to  redeliver  licenses  to  the 
CFI  if  the  licenses  are  already  on-hand  at  the  CFI  for  the  current  version  of  the  COTS  software. 
Contact  the  DISA  CM  Division  if  further  clarification  is  required. 

5.6.2  Kernel  Platform  Certification  (KPC)  Program  Operating  System  Licensing 
Requirements 

Three  (3)  copies  of  the  operating  system  are  required  by  the  CFI  for  the  Test  and  Evaluation 
Division,  the  Product  Integration  Division,  and  the  DII  COE  Engineering  Office  for  every  kernel 
submitted  to  the  CFI  under  the  direction  of  the  Kernel  Platform  Certification  Program.  These 
licensed  operating  systems  are  used  to  perform  DII  COE  kernel  certification  testing. 

5.7  Classified  or  For  Official  Use  Only  (FOUO)  Deliveries 

This  section  provides  developers  the  guidance  on  how  to  make  FOUO  or  classified  deliveries  to 
the  DISA  CM  Division.  The  developer  must  follow  DOD  procedures  for  the  transmittal  of 
classified  information.  Deliveries  can  be  couriered  to  the  OSF  by  the  delivery  personnel  or  mailed 
via  proper  procedures  to  the  building.  The  transmittal  should  be  addressed  to  either  the  Media 
Control  Officer  or  to  the  Security  Officer. 


When  the  developer  contacts  the  DISA  CM  Division  to  schedule  the  delivery  they  must  inform 
the  scheduler  that  it  will  be  a  classified  delivery.  In  all  likelihood  the  documentation  associated 
with  a  classified  delivery  will  be  unclassified.  If  this  is  not  the  case  then  the  scheduler  must  also 
be  informed  that  the  delivery  will  contain  classified  documentation  in  addition  to  classified 
software.  The  developer  should  make  every  effort  to  keep  the  Delivery  Letter  and  Delivery 
Checklist  unclassified.  Proper  labeling  and  classification  marking  must  be  used  to  include  title  and 
paragraph  classification  marking.  This  will  help  the  DISA  CM  Division  during  the  processing  of 
the  delivery.  Should  additional  information  on  FOUO  or  classified  deliveries  be  required,  please 
contact  the  DISA  CM  Division. 

5.8  Exportability  and  Foreign  Military  Sales  (FMS)  Additional  Guidance 
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The  DII  COE  and  GCCS  software  releases  will  be  used  for  FMS  purposes.  It  is  imperative  that 
documentation  and  software  be  properly  identified  that  contain  release  restrictions  that  prevent 
their  use.  Additional  information  and  guidance  on  export  restrictions  can  be  found  at 
http://www.deskbook.osd.mil. 

Additional  markings  will  be  required  for  those  DII  COE  and  GCCS  documents  and  software 
segments  that  have  export  restrictions.  This  is  because  DoD  Directive  5230.24,  Distribution 
Statement  on  Technical  Documentation ,  requires  that  all  DoD  Components  that  generate  or  are 
responsible  for  technical  documents  determine  their  distribution  availability  and  mark  them 
appropriately  before  primary  distribution.  Managers  of  technical  programs  are  required  to  assign 
appropriate  distributions  statements  to  technical  documents  generated  within  their  programs  to 
control  the  secondary  distribution  of  those  documents.  Therefore,  technical  data  with  military  or 
space  application  also  must  be  marked  with  a  prescribed  export  warning  statement,  in  addition  to 
other  markings  authorizing  or  restricting  secondary  distribution. 

Besides  those  documentation  requirements  identified  in  the  DDR,  the  following  statement  must  be 
added  to  the  cover  page  of  all  DII  COE  and  GCCS  documents  being  delivered  to  the  CFI  that  are 
export  restricted.  The  warning  that  must  be  include  is: 

AVARNING  -  This  document  contains  technical  data  whose  export  is  restricted  by  the  Arms 
Export  Control  Act  (Title  22,  U.S.C.,  Sec  2751,  et  seq.)  or  the  Export  Administration  Act  of  1979, 
as  amended,  Title  50,  U.S.C.,  App  2401  et  seq.  Violations  of  these  export  laws  are  subject  to 
severe  criminal  penalties.  Disseminate  in  accordance  with  provision  of  DoD  Directive  5230.25" 

All  electronic  media  being  delivered  with  the  release-restricted  documenation  and  software  also 
requires  a  similiar  type  labeling.  However,  documentation  softcopies  and  software  media,  will 
use  an  abbreviated  marking.  The  abbrieviated  label  marking  will  say  /EMS-Export  Controlled 
Technical  Data.@Below  are  examples  of  both  a  softcopy  documentation  diskette  and  a  segment 
media  labels. 


Softcopy  documentation  diskette  label  example: 


Segment/Program  Name/Version  Number: 
Document  Title: 

Version  Number: 

Filename: 

Sequence:  N  of  M 
Material  Date: 

Security  Classification: 

CM  Number: 

FMS -Export  Controlled  Technical  Data 


Segment  media  label  example: 


Software  name: 

Version/Patch  Number: 

Media  Number:  (1  of  2,  2  of  2,  etc.): 
MASTER  or  BACKUP  copy: 
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Material  Date:  (YYYYMMDD  format): 

Procedure  used  to  create  media:  (tar,  Makelnstall,  diskcopy,  etc.) 

Operating  System:  (Solaris  2.5.1,  HP-UX  10.20,  NT  4.00,  etc.) 

Program  Name/Version:  (DII  COE,  GCCS  3.0,  GCCS  3.1,  etc.  Note:  Do  not  use  a  DII  COE  Version  Number) 

Security  Classification:  (Unclassified,  FOUO,  Confidential,  Secret,  Top  Secret,  etc.  Note:  The  classification  must  be  in  bold  font.) 
Type  media  (4mm,  8mm,  3  2  "  diskette,  CDROM,  etc.) 

CM  Number: 

FMS-Export  Controlled  Technical  Data 


Should  clarification  or  additional  information  be  required  concerning  marking  requirements, 
please  contact  the  DISA  FMS  Office.  Address  comments  and/or  concerns  to: 

Mr.  Steve  Goya  unclassified  email:  goyas@ncr.disa.mil 

DISA/D62  phone:  (703)  681-2037 

5600  Columbia  Pike  fax:  (703)  681-2791 

Falls  Church,  VA  22041 

6  Waiver  Process 

6.1  General  Waiver  Information 

The  following  sections  identify  the  waiver  process  used  for  exceptions  to  this  document.  In  many 
cases  the  DISA  DII  COE  Engineering  Office  and  the  DISA  GCCS  Engineering  Office  responsible 
for  these  joint  programs  have  elected  to  automatically  issue  waivers  for  specific  circumstances 
under  their  control.  Please  cite  the  document,  paragraph,  and  exception  number  when  filling  out 
the  Delivery  Letter  and  the  Delivery  Checklist  for  any  automatic  waiver  issued. 

6.2  How  to  Request  a  Deviation  to  the  CM  Delivery  Process 

Requests  for  deviations  to  the  CM  delivery  process  delineated  in  this  document  must  be  submitted 
to  the  DISA  CM  Division  Chief.  For  example,  a  government  or  contractor  developer  may  request 
to  submit  Solaris  segments  on  4mm  tape  media  instead  of  the  8mm  media  requirement  identified 
in  Table  3.  The  deviation  request  must  specify  what  exceptions  are  being  asked  for,  the  rationale 
behind  such  request,  and  the  program  affected  (DII  COE  or  GCCS).  The  DISA  CM  Division  will 
coordinate  with  the  appropriate  engineering  office  for  disposition  of  the  request.  Requests  may 
be  sent  to  the  DISA  CM  e-mail  account  or  to  the  address  on  the  front  of  this  document. 

6.3  Waivers  Issued  by  the  DII  COE  Engineering  Office 
6.3.1  Automatic  Waivers 

The  DII  COE  Engineering  Office  automatically  issues  waivers  for  certain  circumstances  and  types 
of  software  deliveries.  These  automatic  waivers  are  fisted  in  the  Defense  Information 
Infrastructure  (DII)  Common  Operating  Environment  (COE)  Developer  Documentation 
Requirements  (DDR),  current  version,  document. 
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6.3.2  Waivers  Issued  at  DII  COE  Critical  Design  Reviews 


The  DII  COE  Engineering  Office  conducts  Critical  Design  Reviews  (CDRs)  for  the  DII  COE 
kernels  and  for  every  application  in  the  Infrastructure  Services  and  Common  Support  Application 
layers.  Two  of  the  mandatory  areas  covered  during  the  CDRs  are  software  exceptions  to  the 
I&RTS  and  delivery  requirement  exceptions  to  this  document.  An  electronic  mail  message  is 
generated  by  the  DII  COE  Engineering  Office  granting  waivers  and  exceptions  for  both  areas 
shortly  after  the  CDR  is  held.  The  subject,  originator,  date,  and  time  of  the  electronic  mail 
message  must  be  referenced  when  filling  out  the  Delivery  Letter  and  the  Delivery  Checklist  for 
any  waiver  issued.  Developers  of  DII  COE  kernels  and  applications  do  not  need  to  contact  the 
DISA  CM  Division  concerning  waivers  unless  they  are  asking  for  additional  waivers  not  listed  in 
the  current  DII  COE  DDR  or  issued  at  the  CDR. 


6.4  Waivers  Issued  by  the  GCCS  Engineering  Office 

The  GCCS  Engineering  Office  will  approve  and  issue  waivers  on  a  case  by  case  basis.  Should 
clarification  or  additional  information  be  required  concerning  the  waiver  process  for  GCCS 
mission  applications,  please  contact  the  GCCS  Engineering  Office.  Address  comments  and/or 
concerns  to: 


GCCS  Engineering  Office 
DISA/D63 

45335  Vintage  Park  Plaza 
Sterling,  VA  20166-6701 


unclassified  email:  gccseng@ncr.disa.mil 
unclassified  phone:  (703)  735-8712,  8643, 
8948,  8719,  or  8535  (DSN  Prefix  653) 
unclassified  fax:  (703)  735-8504 


7  References 

The  following  references  form  the  basis  for  this  document.  Soft  copies  of  these  documents  are 
available  electronically  from  DISA  maintained  web  sites.  Please  see  Section  8  for  the  web 
addresses. 

Defense  Information  Infrastructure  (DII)  Common  Operating  Environment  (COE) 
Integration  and  Runtime  Specification  (1  &RTS ),  Version  3.0,  1  July  1997,  CM-400-01-04. 

Defense  Information  Infrastructure  (DII)  Common  Operating  Environment  (COE)  User 
Interface  Specifications  (Style  Guide),  Version  2.0,  1  April  1996,  CM-400-18-03. 

Defense  Information  Infrastructure  (Dll)  Common  Operating  Environment  (COE)  Kernel 
Platform  Certification  Program ,  Draft,  Version  0.8,  10  October  1997. 

Defense  Information  Infrastructure  (DII)  Common  Operating  Environment  (COE) 
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Developer  Documentation  Requirements  (DDR),  Version  2.0,  23  January  1998,  CM-400-2 14-04. 


8  DII  COE  and  GCCS  Web  Site  Addresses 

The  following  URLs  can  be  used  to  access  information  concerning  the  DII  COE  or  GCCS 
programs. 

Unclassified  Web  Sites: 

DII  COE:  http://spider.osfl.disa.mil/dii/ 

GCCS:  http://spider.osfl.disa.mil/ 

Secret-level  Web  Sites: 

DII  COE:  No  capability  exists  at  this  time 

GCCS:  http://trudel.disa.smil.mil/ 
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Appendix  A:  Delivery  Letter  Template 

The  following  instructions  will  aid  developers  in  filling  out  the  Delivery  Letter  template. 
Clarifying  information  and  instructions  are  provided  for  each  section.  If  more  clarification  is 
required,  please  contact  the  DISA  CM  Division.  [Remove  this  paragraph,  the  appendix  title,  and 
then  supply  all  bracketed  ^[...] (Remaining  information.  These  pages  can  then  serve  as  your 
electronic  template  for  filling  out  the  delivery  letter.] 

Delivery  Letter 

Version  3.0 


Date:  [Insert  the  date  in  YYYYMMDD  format.] 

To:  Defense  Information  Systems  Agency  (DISA) 

Joint  Interoperability  Engineering  Organization  (JIEO) 

Chief,  Configuration  Management  Division 
45335  Vintage  Park  Plaza 
Sterling,  VA  20166-6701 

From:  [Insert  the  name,  organization,  and  mailing  address  of  delivery  source.] 

Subject:  Delivery  or  Redelivery  of  [Insert  programmatic  document,  kernel,  or  segment  name 
(As  fisted  in  SegName  file.)],  Version  No. [Insert.  (As  fisted  in  Version  file.)] 

1.  Letter  accompanies: 

A.  Delivery  Checklist  dated:  [Insert  the  date  in  YYYYMMDD  format.] 

Note:  Additional  items  are  contained  on  this  checklist  that  will  be  required  at  the  time  of 
delivery. 

B.  Formal  delivery  name:  [Insert  the  name  of  the  programmatic  documentation  or  kernel 
being  delivered.  If  it  is  a  segment  delivery,  this  item  must  exactly  match  the  segment  name  as 
identified  in  the  SegName  descriptor  file.  For  additional  information  on  the  SegName  descriptor 
file,  consult  paragraph  5.5.1.10  of  the  I&RTS.] 

Note:  All  hardcopy  documentation  titles,  softcopy  documentation  labels,  and  executable  software 
tape  labels  must  match  if  all  three  are  present  in  the  type  of  delivery. 

C.  Version  number:  [Insert  the  version  number  of  the  kernel,  segment,  or  programmatic 
documentation  being  delivered.  For  software  deliveries,  please  include  all  designations  after  the 
(/)  slash  in  the  version  number  if  the  (/)  slash  option  is  used.  The  version  number  must  come  from 
the  Version  descriptor  file  for  all  segments.] 

D.  Segment  Prefix:  [If  this  is  a  segment  delivery,  insert  the  segment  prefix  as  it  is  identified  in 
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the  SegName  descriptor  file  internal  to  the  segment.  If  this  is  not  a  segment  delivery  mark  this 
N/A.] 

E.  Material  date  is:  [Insert  the  date  of  creation  of  the  programmatic  documentation  or 
software.] 

Note:  All  hardcopy  documentation  titles,  softcopy  documentation  labels,  and  executable  software 
tape  labels  must  match. 

F.  OS:  [Insert  the  type  and  version  of  the  operating  system.] 

For  example,  insert  Solaris  2.5.1,  HP-UX  10.20,  SGI  IRIX  4.2,  NT  5.0,  etc. 

G.  Documentation/Software  is  intended  for:  [Insert  the  program  name;  DII  COE,  GCCS,  or 
Kernel  Platform  Certification.  For  GCCS  deliveries,  include  the  targeted  GCCS  release  version.] 

2.  This  submission  supersedes  the  following  software:  [Insert  the  name  of  the  kernel,  segment,  or 
programmatic  documentation,  version  number,  and  date  of  item  this  delivery  supersedes.] 

Note:  If  the  delivered  software  and/or  documentation  replaces  or  upgrades  previously  delivered 
software  and/or  documentation,  a  reference  to  the  date  and  subject  of  the  previous  delivery  letter 
that  accompanied  the  now  superseded  or  upgraded  software  and/or  documentation  must  be 
included. 

3.  Regarding  types  of  software: 

A.  Is  the  segment  being  delivered  COTS  or  GOTS?  [Answer  COTS  or  GOTS.] 

B.  Does  the  GOTS  segment  contain  COTS  products?  [Answer  Yes,  No,  or  N/A  for  COTS.] 

C.  Have  the  appropriate  COTS  licenses  been  attached  to  this  delivery  letter?  [Answer  Yes  or 
No.  If  No,  then  an  explanation  must  be  provided  stating  why  the  licenses  are  missing.] 

D.  For  COTS  segments,  are  they  Freeware  or  Shareware?  [Answer  No,  Yes-Freeware,  or 
Yes-Shareware.] 

NOTE:  IAW  paragraph  5.7,  Temporary  Licenses  for  Test,  Integration,  and  Evaluation  Purposes, 
three  licenses  are  required  at  the  time  of  delivery  of  each  COTS  application  being  delivered  in 
segmented  form.  This  requirement  holds  true  for  GOTS  applications  with  embedded  COTS. 
Three  licenses  must  be  provided  for  each  COTS  application  embedded  in  GOTS  software. 

4.  This  segment  submission  requires  the  following  software  be  loaded  prior  to  installation: 

[Insert  the  operating  system  name  and  version  and  then  a  breakdown  of  the  segment  name  and 
version  for  each  required  DII  COE  or  GCCS  component.] 


NOTE:  I&RTS,  Paragraph  5.5.2.23,  Requires,  identified  how  software  developers  are  to  state 
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segment  dependencies.  This  section  of  the  delivery  letter  should  contain  the  same  information  as 
the  segment  descriptors  portion  of  the  executable  software  code. 

5.  A  short  description  of  the  software  functionality  is:  [Insert  a  one  paragraph  description  of  the 
software  being  submitted.  This  would  be  N/A  for  documentation  only  deliveries.] 

6.  This  submission  includes  changes/fixes  to  the  following  GSPRs:  [Either  list  all  GSPRs 
allegedly  fixed,  list  /None@f  no  GSPRs  were  fixed  with  the  redelivery,  or  list  N/A  if  this  is  a  first- 
time  software  delivery  or  programmatic  documentation  only  delivery.] 

NOTE:  Though  a  software  developer  may  indicate  what  GSPRs  they  have  attempted  to  fix,  the 
GSPRs  are  not  closed  until  DISA  CFI  personnel  have  verified  the  fix  actions. 

7.  Documentation  applicable  to  this  software  submitted  includes:  [List  all  pertinent 
documentation  whether  previously  delivered  or  submitted  as  part  of  this  delivery.] 

A.  Full  Document  Title: 

CM  Number: 

Material  Date: 

Previous  Version:  [Insert  Title,  CM  Number,  and  Material  Date.] 

B.  Full  Document  Title: 

CM  Number: 

Material  Date: 

Previous  Version:  [Insert  Title,  CM  Number,  and  Material  Date.] 

C.  Etc.  [Continue  listing  documents  until  all  those  identified  in  the  DII  COE  DDR  not 
waived  are  listed.] 

8.  For  GCCS  Segment  Release  Bulletins,  what  site(s)  will  use  this  software  segment:  [Choose 
the  selections  that  apply  to  the  segment,  e.g.,  DB  sites  only,  Non-DB  sites,  All  sites,  Single¬ 
service  sites,  etc.  For  DII  COE  deliveries  please  use  N/A.] 

9.  Release  restrictions: 

A.  Are  there  any  intellectual  property  rights  (IPRs)  restrictions  associated  with  the 
documentation  or  software  included  in  this  delivery?  [Answer  Yes  or  No.  An  IPR  agreement 
must  accompany  all  software  deliveries  even  if  there  are  no  restrictions.] 

B.  Are  there  any  technical  exportability  issues  associated  with  this  documentation  or  software 
delivery?  [Answer  Yes  or  No.  If  /V es@plcasc  provide  an  attachment  with  clarifying  information 
as  appropriate  stating  why  the  product  is  not  exportable.  For  example,  a  COTS  segment  may 
contain  algorithms  that  are  not  releasable  outside  the  United  States.  Additionally,  all  of  the 
labeling  requirements  identified  in  paragraph  4.8  must  be  followed.  If  As' o@s imply  state  A\onc@ 
on  both  the  delivery  letter  and  the  delivery  checklist.] 

C.  Are  there  any  specific  release  restrictions  that  would  prevent  the  software  from  being  used 
for  foreign  military  sales  or  being  released  to  private  industry  outside  of  information  provided  in 
question  9B?  [Answer  Yes  or  No.  If  yes,  please  provide  clarifying  information  as  appropriate. 
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Again,  all  of  the  labeling  requirements  identified  in  paragraph  4.8  must  be  followed.] 

10.  Vendor- Assessed  DII  COE  Compliance  Level  (1  to  8): 

NOTE:  This  is  a  self-evaluation  of  the  software  segment  performed  by  the  developer  using 
Tables  B1  through  B8from  the  I&RTS.  This  does  not  imply  the  DII  COE  Engineering  Office 
has  approved,  certified,  or  validated  the  vendors  results. 

11.  Year  2000  (Y2K)  Compliance: 

A.  Is  segment  Y2K  compliant?  In  the  context  of  this  question,  Year  2000  compliance  is 
defined  as  the  capability  of  segments  to  accurately  process  date  data  (including,  but  not  limited  to, 
calculating,  comparing,  and  sequencing)  as  we  approach  and  continue  into  the  next  millennium. 
[Answer  Yes  or  No.] 

B.  If  A  is  Yes,  provide  a  brief,  one  paragraph  description  of  the  test  process  used  in 
determining  Y2K  compliance.  [Insert  information  as  necessary.] 

C.  If  A  is  No,  when  is  the  expected  delivery  date  for  a  Y2K  compliant  segment?  [Insert  the 
estimated  date  in  YYYYMMDD  format.] 

D.  Does  the  segment  process  dates  in  the  DOD  standard  date  format  of  YYYYMMDD? 
[Answer  Yes  or  No.] 

E.  If  the  Software  Test  Plan  (STP)  and  Software  Test  Description  (STD)  were  required  by 
the  cognizant  engineering  office  for  this  delivery,  do  they  include  Y2K  test  cases?  [Answer  Yes 
or  No.] 

NOTE:  In  the  case  of  COTS  applications,  please  attach  a  copy  of  the  vendors  statement 
concerning  Y2K  compliance  to  the  Delivery  Letter. 

12.  Sponsoring  Service/Agency  POC  for  delivery:  [Insert  information  as  appropriate.  NOTE: 
This  must  be  one  of  the  voting  members  of  the  DII  COE  Architectural  Oversight  Group  (AOG). 
The  membership  of  the  DII  COE  AOG  can  be  found  on  the  DII  COE  Homepage  under  the  AOG 
subpage.] 

A.  Name/Grade: 

B.  Telephone: 

C.  Fax: 

D.  E-email  address: 

13.  Government  COR/POC  for  delivery:  [Insert  information  as  appropriate.] 

A.  Name/Grade: 

B.  Telephone: 

C.  Fax: 

D.  E-email  address: 

14.  Developer  Technical  POC  for  delivery:  [Insert  information  as  appropriate.] 

A.  Name/Grade: 

B.  Telephone: 

C.  Fax: 
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D.  E-email  address: 


15.  Individual  performing  delivery:  [Insert  information  as  appropriate.  This  section  may  contain 
hand  written  entries  filled  out  during  the  delivery  meeting.] 

A.  Name/Grade: 

B.  Telephone: 

C.  Fax: 

D.  E-email  address: 

16.  Developer  Information:  [Insert  information  as  appropriate.] 

A.  Contract  Number: 

B.  Task  Number: 

C.  CDRL  Number: 

D.  Other  Comments: 

17.  Software  Media  Contents:  [If  the  delivery  is  for  software  with  multiple  files,  segments,  or 
scripts  included,  the  individual  items  contained  on  the  media  must  be  listed  below.  This  table 
must  also  be  replicated  on  the  delivery  letters  for  each  item  mentioned  in  the  table.  See  paragraph 
5.6.2  for  more  information.  Please  provide  a  descriptive  software  name.  The  table  must  also 
have  the  segment  name  (32  characters  maximum)  ,  prefix  (6  characters  maximum)  and  the  version 
number  (to  include  any  information  after  the  slash)  as  it  is  identified  in  the  SegName  and  Version 
descriptor  files  internal  to  the  segment  for  multiple  segment  deliveries.  The  CM  Librarian  will  fill 
out  the  CM  Number  column.] 


Software  Name: 

SegName: 

Prefix: 

Version: 

CM  Number: 

Note:  The  container  CM  number  for  multiple  segments  on  a  media  will  be  CM  Number: 


18.  For  segment  deliveries,  did  the  segment  successfully  load  on  a  DII  COE-compliant 
workstation  using  the  COEInstaller  at  the  developers  site?  [Answer  Yes,  No,  or  N/A.] 

19.  Additional  Comments:  [Insert  supporting  information  as  appropriate.] 
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Appendix  B:  Delivery  Checklist  Template 


The  following  instructions  will  aid  developers  in  filling  out  the  Delivery  Checklist  template.  The 
checklist  is  a  simple  means  for  accounting  for  all  documentation  that  must  be  provided  with  each 
software  delivery.  If  five  segments  are  being  delivered  then  there  must  be  five  checklists.  Items 
are  either  provided  with  the  software  delivery  or  they  are  not.  In  the  case  of  items  not  provided, 
listed  as  /N/A@a  reason  must  be  included  in  the  Comments  column.  The  only  reason  an  item 
cannot  be  provided  is  because  the  cognizant  engineering  office  has  issued  a  waiver.  For  all  N/A 
entries,  the  subject,  originator,  date,  and  time  of  the  electronic  mail  message  granting  the  waiver, 
a  reference  from  the  DII  COE  DDR,  or  a  reference  to  the  automatic  GCCS  issued  waivers 
identified  in  this  document  must  be  included.  Additionally,  a  copy  of  the  cognizant  engineering 
office  =5=  e-mail  granting  any  waivers  must  be  attached  to  this  checklist. 

The  Delivery  Checklist  is  not  required  for  programmatic-only  documentation  deliveries.  The  item 
should  be  listed  as  /Not  Required@m  the  Delivery  Letter.  If  further  clarification  is  required 
concerning  how  to  fill  out  the  Delivery  Checklist,  please  contact  the  DISA  CM  Division. 
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Delivery  Checklist 

Version  3.0 

Formal  segment  name  (As  listed  in  SegName  file): 

Version: 

Material  Date: 

Operating  System: 

@>r  N/A*  Item  Comments 

Delivery  Letter 

Installation  Procedures  (IP)  Dll  COE  Only 

Software  Version  Description  (SVD) 

System  Administrators  Manual  (SAM) 

Users  Manual  (UM) 

Software  Product  Specification  (SPS) 

Database  Design  Document  (DBDD) 

Software  Test  Plan  (STP) 

Software  Test  Description  (STD) 

Software  Test  Report  (STR) 

Application  Program  Interface  Reference 
Manual  (APIRM) 

Programmers  Manual  (PM) 

Software  Design  Description  (SDD) 

Interface  Design  Document  (IDD) 

GCCS  Segment  Release  Bulletin  (SRB) 

GCCS  Only 

DII  COE  Kernel  Platform  Certification 
Application  Form  KPC  Only 

Government  Supplied  Kernel  Software  (GSKS) 

Build  Document  KPC  Only 

Printouts  of  the  contents  of  the  SegName  and 
Version  Descriptor  Files 

Two  (2)  copies  of  executable  software  media 

(Labeled  MASTER  and  BACKUP) 

Three  (3)  License  Agreements 

(COTS  Segments  Only) 

Intellectual  Property  Rights  Agreement 
Attachment 

COTS  Vendor  Y2K  Compliance  Attachment 
Faxed  CM  Notification  Pages 

*  NOTE:  For  all  N/A  entries,  the  subject,  originator,  date,  and  time  of  the  electronic  mail  message  granting  the 
waiver,  a  reference  from  the  DII  COE  DDR,  or  a  reference  to  the  automatic  GCCS  issued  waivers  must  be 
included.  Additionally,  a  copy  of  the  cognizant  engineering  officer  e-mail  granting  any  waivers  must  be  attached 
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to  this  checklist. 
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Appendix  C:  GCCS  Segment  Release  Bulletin  (SRB)  Template 


The  following  format  is  to  be  used  by  GCCS  developers  to  produce  GCCS  Segment  Release 
Bulletins  (SRBs).  SRBs  are  intended  to  be  simple  but  thorough  instructions  that  a  GCCS  system 
administrator  can  copy  and  hand  out  to  minimally  qualified  installers.  All  user-related  information 
in  previous  SRB  formats  has  been  moved  to  version  description  documents. 

Segment  Name  (as  appears  in  COEInstaller),  Version 
Segment  Description 

Place  segment  abstract  here.  The  segment  abstract  provides  a  brief  (roughly  6  line)  description  of 
the  segment,  particularly  it  =5=  role  relative  to  the  application  it  supports  and  other  segments  related 
to  the  application. 

Installation  Instructions 

List  each  step  in  the  format  shown  below.  Be  sure  to  consider  processes  that  need  to  be  shutdown 
and  segments  that  need  to  be  deinstalled.  In  no  segments  need  to  be  deinstalled,  state  /NONE. (3) 

Step  1:  (example)  Shut  down  any  programs  or  processes  as  necessary  to  ensure  proper 

installation  of  the  segment: 

Step  2:  Deinstall  the  following  segments  (list  each  on  a  separate  line): 

Segment  1 
Segment2 

Step  3:  Verify  installation  of  required  segments: 

List  whichever  segments  are  required  to  install  this  particular  segment.  This 
should  match  the  requires  file  in  the  SegDescrip  directory. 

Step  4:  Install  SEGMENT  (Prefix),  Version  Number. 

Example:  Install  AHQ  5.6.02. 

Dialog  presented  to  the  installer 

List  the  dialog  boxes  that  are  presented  to  the  installer  of  the  segment;  include  screen 
snapshots  if  possible.  If  no  dialog  is  presented,  state  in  this  section,  /No  dialog  is  presented.@ 

Post  Installation  or  Configuration  Instructions 

Identify  in  this  section  any  important  information  needed  to  set  up,  configure  or  prepare  the 
segment  for  use  after  installation.  In  most  cases,  there  are  none.  If  so,  state  /NONE.@ 
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End  of  Document 
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